凌云时刻
作者丨马云飞移动互联网时代的音视频应用如直播购物、远程会议、短视频、云游戏已经彻底改变了人们的生活。这些应用的背后，离不开音视频网络传输技术的发展与支撑。近日，在国际计算机网络通信顶级学术会议 SIGCOMM 上，阿里云智能发表了三篇音视频传输相关的论文，向业界展示了阿里巴巴如何通过构建“可预期音视频网络”的基础设施来支撑阿里巴巴如淘宝，钉钉，云游戏，无影等诸多核心业务。本文将对这三篇论文做一个深度的解读。
视频内容的消费已成为当今人们生活的一个重要组成部分，我们刷剧、购物、玩转社交网络、远程会议办公以及打游戏等，都离不开通过广域网/移动网络传输的大量音视频内容。随着我们进入元宇宙时代，新一代视频应用的爆发，如 AR 和 VR、6DoF……对于网络速率、时延、连接数量和稳定性等方面都提出了更高要求。- 在带宽方面，我们从 360p 视频进化到 4K，对带宽需求提升了 40 倍；
- 在时延方面，以前主流的应用是 VoD 视频，延时在 5s 甚至以上，而现在我们更需要实时的音视频服务，端到端的时延需求在 100ms 以下；
- 在通信规模方面，原来我们开视频会议，主要是 2-3 人的小方会，而现在我们有很多的应用需要支持千人以上的大方会。
所以这里的核心问题就是，我们的需求在过去几年发生了飞快的变化，但我们网络侧的移动连接和传输能力是否已做好准备？我们经常与视频开发者一起合作，不管是内部还是外部，最常听见的就是视频应用的开发者说：“我看过网络的 spec，你们网络应该是可以支持我这个视频业务的。” 但实际实况是，移动互联网其实并不能达到视频开发者的预期。一个很重要的原因就是所有的网络技术都在宣传他们的峰值参数，而这些峰值参数是在非常理想的条件下测量出来的，它代表了当前技术能力上限，并非网络在实际应用中所能够表现出来的。因此，这里面有一个巨大的鸿沟。图1 | (a) 理想情况下的网络（b）现实中的网络
举一个例子，图 1 中（a）是一个理想情况下 LTE 测速应该达到的效果，可以看作是我们的预期，一个下行 270Mbps，上行 45Mbps 的网络。而（b）是我在家中测试得到的结果，下行 5.5Mbps，上行只有 600Kbps。这里可以看出移动网络具有非常大的不确定性，这也给音视频应用带来很大的挑战。音视频产品的核心竞争力在于其体验，由于它们是承载在云之上的，那么复杂多变的网络环境必然有很大的影响。图2 展示了一个简单的音视频传输模型，在推流端将媒体流发送给接收端的过程中会经过上下行的无线网络和广域网络，存在信道质量变化快、资源竞争激烈、网络拥塞严重、丢包率高等情况。经过长期探索，我们发现：其根本的解决方法就是去演进我们的视频网络传输技术，使服务变得更加的可预期，进而从根本上提升用户体验。为此，在过去几年中，我们针对不同业务场景，在码率控制、路径控制、拥塞控制等不同维度深耕技术，并取得了若干突破（如表1 所示）。表1ACM SIGCOMM 2022，阿里巴巴在“可预期音视频传输”方向的三个系统所针对的不同音视频应用场景与技术侧重。
「 GSO-Simulcast 」
音视频会议的全局码率控制系统在多人视频会议中，保证低延时、高清晰度、流畅通话体验是最核心的任务。但大规模的实时音视频会议是一个非常具有挑战性的场景，其原因在于多方会议中不同参会者处于截然不同的网络环境，从而导致网络的“瓶颈”效应。
图3 | 多人音视频会议中，不同参会者处于“截然不同”的网络环境，从而导致网络的“瓶颈”效应如图3 所示，图中有三个拉流者 (sub1, sub2, sub3) 订阅了推流者（pub1）的视频流，但这三个拉流者处于不同的网络环境，他们的下行侧带宽分别是 2Mbps、1Mbps 和 500Kbps。问题来了，推流者 pub1 究竟需要推多大的视频流？从图中可以看到，如果 pub1 推一个 2Mbps 的流，那么 sub1 将会得到最好的体验，可这将导致 sub2 和 sub3 发生卡顿，因为他们的带宽不足以支持这么高的码率。最终，为了避免拉流卡顿，pub1 不得不发送一个低于 500kbps 的视频流，虽然这样避免了卡顿，但却不可避免地拖累了 sub1 和 sub2 的观看体验。从这个简单的例子可以看出，一个多方会议中的音视频体验总是会受限于那个处于“瓶颈”网络环境的参会人。随着会议人数的增加，所有参会人中处于“弱网”环境的参会人概率也在增加。克服多人会议中的瓶颈效应是提供流畅音视频服务的关键。
Simulcast 技术可以帮助我们解决不同参会者所处网络环境不一的问题，一个简单的 Simulcast 原理图如图4 所示。在 Simulcast 中，推流者将同一个视频源编码成不同码率的版本，并将这些视频流并行发送至 SFU 服务器，SFU 服务器接收到这些流以后根据观测到的不同拉流者的下行带宽进而转发不同的码率版本。例如，SFU 服务器向拥有高带宽的 sub1 推送高码率，向拥有中等带宽的 sub2 推送中码率，向处于弱网环境的 sub3 推送低码率。这样每一个接收方都能得到自己最适合的码率，同时避免了下行的卡顿。在 Simulcast 中最关键的部分就是 Simulcast Stream Policy，它决定了两件事情：可以说 Stream Policy 是 Simulcast 的核心。目前业界的典型方案如下图所示：图5 | AWS Chime 的 Simulcast Stream Policy,
https://aws.github.io/amazon-chime-sdk-js/modules/simulcast.html图5 展示了 AWS Chime 所使用的 Stream Policy，它本质上是一个经验表（Empirical Table）。AWS Chime 会根据会议的参会人数，上行带宽大小，通过查表定出需要推哪几条流，并且每条流的码率是多少。这样的经验式的 Stream 策略也有很多局限，特别是在参会人数变多的情况下：（1）这种通过查表来决定码率数量和大小的过程中只参考了推流者的上行带宽，对于拉流者的订阅需求和相应的下行带宽并没有考虑进去，这样就造成了 Stream Policy 与下行需求和带宽约束之间的孤立，无法按需推流。（2）目前的 Stream Policy 采用的码率档位颗粒度非常粗，而且档位的个数也很少，相邻的档位间码率差异可以达到 3-4 倍。这虽然简化了 table 的复杂度，但这样的粗颗粒度也造成了码率与带宽之间失配的问题。（3）这种经验策略在会议规模扩大之后是很难去扩展和管理的，Chime 只对参会人数在 6 人以下做了细分，而在会议人数大于 6 人的情况下不做进一步的划分。但是，我们看到，当前的会议通常具有很大的参会人数，可以达到数百甚至上千，而在大方会中要制定出这样一个经验策略是非常困难的，因为变量的维度实在是太大了，这时，我们的测试团队已经无法对于各种 case 进行枚举来确定出最优策略。面对这样的问题，我们需要考虑一下 Simulcast 会议的终局究竟是什么：理想情况下无论参会者人数如何变化，订阅需求如何变化，用户的上/下行带宽条件如何变化，我们都能完美地匹配音视频码率档位与网络环境。首先，这要求我们能够支持尽量多的从细粒度档位去适配不同的网络带宽。但是档位的增加又会导致上行的推流个数增加，盲目地推更多条流又会导致上行拥塞，所以我们决定在上行推流的过程中必须将下行订阅需求与带宽约束条件联合起来，做到按需推流。另一方面，我们需要支持成百上千人的大方会议，这就导致我们无法继续使用基于 empirical table 的 stream policy，而要把 stream policy 转化为一个可以自动求解的优化问题。所以，我们需要从当前碎片化、孤立化的经验决策中解脱出来，以全局优化的视角重新审视音视频会议码率控制。鉴于此，阿里巴巴提出了 GSO-Simulcast，一个基于全局码率求解器的新一代音视频会议技术。
图6 展示了 GSO-Simulcast 的一个简化架构。GSO-Simulcast 将一个会议分为三个平面，位于最下层的是用户面，它由一个会议的所有参会者组成，其中每个参会者都可以作为推流者或拉流者。在用户层上侧的是媒体面，它的作用是为用户提供媒体，接入媒体流的转发。位于最上层的，也是 GSO-Simulcast 核心的管控面，它的核心模块包括 Conference Node 和 GSO Controller。Conference Node 有两个主要功能：（1）负责与用户与 Accessing Node 之间的信令通信；（2）负责捕获整个会议的全局快照，包括某一时刻：a）所有用户上下行的网络带宽；b）所有用户间的订阅关系；c）所有用户编解码器 codec 的能力。然后 Conference Node 将这些收集的信息作为输入条件传递给 GSO Controller，GSO Controller 是整个会议的大脑，它会以整个会议的全局体验 QoE 为优化目标去求解一个全局优化问题，同时满足所有约束条件。在 GSO-Simulcast 中，我们可以支持多达 15 个细粒度档位的码率，从而实现对各种带宽条件都能做很好的适配。而整个优化问题也使得 Stream Policy 的扩展性大大提升，因为问题的 formulation 是一致的，面对不同的情况只需变化输入，GSO 就会自动求解出对应的输出，这样我们就可以轻松地处理甚至千人以上的会议策略。
图7 | GSO-Simulcast 在钉钉音视频会议的部署效果（百万次/每天的会议抽样数据）部署效果：2021 年 11 月 20 号，GSO-Simulcast 开始在钉钉音视频会议进行部署，并于 2021 年 12 月 20 号达到了全量部署。图7 展示了钉钉会议大盘数据对比变化（数据基于每天百万次会议抽样统计）。结果显示，随着 GSO-Simulcast 的规模扩大，视频卡顿率、音频卡顿率和视频帧率分别改进 35%、50% 和 6%，另外最关键的是在 GSO-Simulcast 上线以后，钉钉音视频会议的用户满意度也同期改进了 7%。第二篇文章是 LiveNet，LiveNet 是阿里巴巴推出的一个面向直播的低延迟 CDN Overlay 网络。与音视频会议需要的～100ms 级别的时延不同，直播对于时延的要求在～1s 级左右。另一方面，一场直播所要服务的用户数量可能达到千万甚至上亿，所以直播网络对于成本更加敏感，直播内容的分发需要用到 CDN 网络提供的就近接入与缓存（Caching）服务。阿里巴巴的第一代直播分发网络采用了分层（Hierarchical）架构，又可以称之为 HIER，其架构如图8 所示。图8 | 阿里巴巴第一代直播内容分发网络 HIERHIER 由流媒体中心（Streaming Center）和 L1、L2 两级 CDN 内容分发节点（node）组成，L1、L2 节点负责分发视频内容，流媒体中心负责对上传的视频进行处理。在直播当中，一个典型的内容分发过程如下：上行侧，主播上传直播内容到相应的 L1 节点（通常，这个节点和用户的物理距离很近），之后由 L1 节点将内容继续上传到一个 L2 节点并由 L2 节点将内容提交给流媒体中心。如果有需要，流媒体中心会对视频内容进行转码等处理。下行侧，经过流媒体中心处理过的视频再通过 L2、L1 两级节点进行分发。同时，L1、L2 节点会对视频的内容进行缓存。观看的用户通过 L1 节点接入拉取相应的视频，如果 L1 上没有缓存的视频，则 L1 节点会向 L2 节点发起请求。节点之间的数据传输是基于 RTMP over TCP 实现的。HIER 架构于 2016 年在阿里上线并支持淘宝直播，多年的实践和应用需求的发展也让阿里发现 HIER 架构存在的若干问题：（1）随着业务的发展，用户对于直播时延的要求越来越苛刻，为了能够实现 <1s 的时延，CDN 的传输时延必须控制在 300-400ms，可是目前 HIER 所能提供的时延在 400ms 左右，因此，我们需要一个更低时延（扁平化）的直播内容分发网络。（2）直播业务的兴起也使直播的会话 (session) 数量爆发式增长，而 HIER 架构当中，所有的视频流都需要经过流媒体中心，这大大增加了媒体中心的处理压力和处理时间，也间接导致了端到端时延的增加。（3）阿里云同时也为第三方应用提供直播内容分发服务，而 HIER 的分层架构缺乏灵活性，这为不同用户提供不同优先级造成了一定的困难。内容分发网络的组网应该可以更加灵活（flexible）。图9 | LiveNet 的系统架构
所以，阿里巴巴打造了新一代直播内容分发网络 LiveNet，其系统架构图如图9 所示。与 HIER 的分级架构不同，LiveNet 是一个基于扁平化结构的 Overlay 网络 CDN 内容分发网络。在 LiveNet 当中，每一个节点可以通过中心化的控制中心（又称作流媒体大脑）配置。在 LiveNet 中，一个典型的直播内容分发过程如下：主播通过访问阿里云 DNS 服务就近接入一个边缘节点，这个节点又称为 Producer 节点。Producer 节点会直接对视频内容做转码等相关的媒体处理。当观众需要观看视频时，观众会向一个边缘节点，又称作 Consumer 节点发起请求，如果请求的视频内容已经被缓存在相应的 Consumer 节点，那么该节点直接返回被请求的视频 GoP。如果 Consumer 节点没有相关的视频内容，那么该节点会向中心控制器发起一个路径请求。中心控制器会返回一条最优的 overlay 路径，这条路径决定了视频内容该如何从一个 Producer 节点，通过中继节点（Relay）传输到一个 Consumer 节点。Consumer 节点和 Relay 节点都可以对视频内容进行缓存，节点之间的流媒体传输由原先的 RTMP over TCP 演进为基于 RTP/RTCP 的传输。LiveNet架构与SDN有很多相似之处，这个系统可以被进一步划分成控制面与数据面。控制面的主要任务是计算出一条全局最优的 overlay 路径。中心控制器会根据全局对网络信息，并考虑各个节点的负载与链路带宽，来计算出一条时延最短的 overlay 路径。数据面则负责按照控制面计算出来的路径传输媒体流，为避免 WebRTC 协议栈带来的处理开销过大的问题，在数据面上，LiveNet 采取了 Fast-slow path 设计，快路径（fast path）采用尽力而为的转发方式将数据包传递给下一跳，而丢包和拥塞控制的逻辑则由慢路径（slow path）处理。
图10 | LiveNet 与 HIER 的关键指标对比如今 LiveNet 已经在超过 600 个 CDN 节点进行了部署，支持着淘宝直播等线上业务，图10 展示了 LiveNet 与 HIER 架构在关键指标上的对比。LiveNet 大幅度降低了 CDN 的路径时延，从原先的 393ms 降低到 188ms。其中最关键的因素是扁平化的 CDN overlay 网络，将视频内容分发需要经过对节点跳数从过去的 4 跳普遍降低为现在的 2 跳。路径时延的降低也使直播时延降低了 17%，卡顿率和快启动等指标也均有提升。无线网络因为信号强度的变化、射频干扰、多人竞争等原因经常表现出不稳定的时延。在游戏环境中，时延波动通常对玩家体验有非常大的伤害。如何在复杂的无线环境中实现低时延的视频传输一直以来都是一个难题。为了降低时延，一个办法是当网络带宽降低时，及时地减少发送端的发送速率。我们都知道一旦出现丢包，发送端的拥塞控制器会降低发送窗口。但丢包现象往往是在路由器队列已经被“塞满”的情况下发生的，可是这个时候再去降低发送端的发送速率往往“为时已晚”。所以问题的关键就在“及时”二字。在第三篇文章中，阿里巴巴推出了一个新的原型系统诸葛（Zhuge），它是一个可以被集成在 WiFi 路由器的低时延视频传输方案。
Zhuge 的原理图如图11 所示，它的核心在于当下行无线带宽变化时，如何将反馈信息更快地传递给发送端。Zhuge 在原理上采用了基于时延（Delay-based）的拥塞控制（Congestion control）。简单来说，这类拥塞控制会观察数据包之间的时延（Inter-packet delay）变化，当 Inter-packet delay 增加时，就可以认为链路的带宽减小，排队时延增加。此时，发送端就可以开始降低速率用来避免排队时延的继续升高。但这类拥塞控制的反馈速度受到整个上下行环路的制约。具体来说，下行链路（Downlink）的数据包发生排队后，这个数据包所历经的传输时延变大，但发送端是如何感知到这个信息呢？通常，发送端会对数据包对应的 ACK 报文的到达时间进行测量，再通过 ACK 报文的到达时间来间接推测下行链路排队时延，也就是说，我们必须要等一个 round-trip 才能感知到这个反馈，并且这个 round-trip 有可能已经包含了一个很大的拥塞队列的排队时延。Zhuge 原型系统提出了一个将反馈信号与拥塞队列解藕的解决方法。一个重要的 insight 就是当下行的数据队列开始堆积时，Zhuge 可以不等被阻塞的数据包的 ACK 信息来反馈拥塞，而是利用比这个数据包更早的数据报文对应 ACK 提前将这个信息反馈给发送端。
具体的操作如图12 所示，拥塞发送在数据包 k 和 k+1 之间，此时，因为 AP 可以测量自身的拥塞队列（图11 Fortune-teller 模块），AP 可以将这个排队时延的信息调制在更早的数据包 j+1，j+2（这里 j<k）相应的 ACK 报文上。简单来说，WIFI AP 可以主动增大 ACK j+1，ACK j+2 之间的时延。当接收方观测到 ACK j+1，ACK j+2 时，便会主动降低发送速率从而以更快的响应速度降低排队时延。在实验结果上，Zhuge 可以将 RTC 的长尾时延降低 17% 至 95%。结语
低时延视频在我们的生活中变得越来越重要，为上层视频业务保驾护航，提供可预期的音视频传输服务与技术是网络基础设施中的关键一环。特别是随着元宇宙时代的来临，视频传输会变得更具挑战性。GSO-Simulcast、LiveNet、Zhuge 分别就音视频会议、直播、游戏等核心业务场景阐述了实现“可预期”目标的三种重要技术手段。未来，阿里云将继续秉持 “做深技术”的理念，为用户提供更可靠的视频服务和创造更大的业务价值。
你可能还想看关注我们欢迎关注加星标✨ 每日推送不错过